I haven't looked closely but it looks like this impl would require adding generics for the runtime API client and other breaking changes? Customers are unlikely to name them but we probably still can't do break that API... Probably we need to cut over to a new type and deprecate the old? What are you thinking?

Adding a non-constrained generic shouldn't be a problem, and it is pretty beneficial in this scenario.

I guess the alternative is injecting a client that communicates over channels.

I am not sure. Maybe there's a different way to test this that I am just missing.

I guess the alternative is injecting a client that communicates over channels.

Big ++ to this - some sort of test-util-feature-gated utility that allows overriding the client with an arbitrary trait implementation, seems great.

Adding a non-constrained generic shouldn't be a problem

Not a problem, but it is semver breaking, in case anybody names the type. (They are unlikely to, but still). Along similar lines, we are adding a new variant to RuntimeApiClientFuture, which is not tagged as #[non_exhaustive], which is also breaking.

I don't think it's a big deal, these are unlikely to be used by end user code, but we probably should play by the rules and add new names for these and deprecate the old? Anyway if we cut over all of our other crates relying on these types, end user churn would be minimal.

I would say RuntimeApiClientFuture is not accessible outside layer because of this rule

The same is for RuntimeApiClientService which has pub(crate) visibility.

So cx cannot infer the breaking enum even through the struct using it.

In this case there's not much sense also in putting also the non_exhaustive

@FullyTyped I'll have a look at this stuff and try to make it prod-ready.

I would say RuntimeApiClientFuture [and Serivce] is not accessible outside layer because of this rule

Looking through, I think that you're right!

It doesn't seem to be exposed as an unnameable type either (ie, using a public type in a private module, but that shows up in a public api). For that, we still might have a problem, since you can still match on it via field accessor syntax.

Can we just move both to pub(crate) in that case? That would pretty clearly flush out public exposure that we are missing.